昨天列了 A2A 定義的四個 method 與四個核心概念，那是協定「做什麼」的清單。今天反過來問：這個協定不做什麼？它的邊界畫在哪裡？

為什麼小是優點

規格小代表實作成本低。A2A server 端真正要自己寫的只有一個 AgentExecutor，大約 20 行，其餘 HTTP、JSON-RPC 解析、task 狀態機、agent card 路由都由 SDK 提供。這件事我會在 Day 17 專門講。

規格小也代表你得自己想清楚一些事。既然協定不做合併，那多方結果誰來整？既然每次委託都是新的 Task，那多輪對話的記憶掛在哪？這兩個問題分別是 Day 12 跟 Day 16 的主題，而且答案都會影響你的雲端帳單。

一個容易誤解的地方

A2A 跟 MCP 常被放在一起講，但職責不同。MCP 處理的是「agent 呼叫工具」，A2A 處理的是「agent 委託 agent」。差別在對方有沒有自己的判斷力：工具是確定性的函式，agent 會自己決定怎麼做。

這個邊界我目前只有文件層的認知，還沒實作過兩者混用的系統，所以先標一句未實測，不把它寫成定論。

不過文件層的界線寫得算清楚。要查資料庫、讀檔案、呼叫外部 API，這些是確定性動作，用 MCP；要請另一個團隊維護的助理幫忙處理一整件事，對方自己有 LLM、會自己判斷怎麼拆解，這個用 A2A。一句話分：MCP 底下沒有自己的判斷力，A2A 底下有。

協定不管的另外三件事

除了不碰工具呼叫這條線，A2A 明確不管的還有三件事。

第一，它不幫你統整資料。委託三家店拿回三份報價，這三份東西要怎麼變成一句話回給使用者，是 orchestrator 那顆 LLM 的工作，token 也算在它頭上，協定本身沒有合併邏輯。

第二，它不幫你選框架。門後面用什麼寫成的，A2A 完全不管，它只規定門口那通電話怎麼講。

第三，它不管身分驗證。你的 agent 要不要驗身分、怎麼驗，A2A 有相關規範但不會替你做，放上公網的 agent 這件事得自己想清楚。

常見誤解對照

整理幾條我自己一開始也搞混的：以為 A2A 會幫忙統整多個 agent 的答案，實際不會，那是 orchestrator LLM 的工作；以為要跟對方用同一個框架才能溝通，實際完全不用，這正是 A2A 存在的目的；以為 A2A 跟 MCP 是二選一，實際兩者管的是不同的事，一個系統裡常常一起用。

協定畫邊界的方式跟它定義四個 method 的方式是同一種脾氣：只管門口的規矩，門裡面的事一概不碰。這種「小」不是偷懶，是刻意把決定權留在你手上。